home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group01a.txt
/
000096_icon-group-sender _Fri Jul 7 14:18:23 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2002-01-03
|
4KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA20851
for icon-group-addresses; Fri, 7 Jul 2000 14:16:41 -0700 (MST)
Message-Id: <200007072116.OAA20851@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Fri, 07 Jul 2000 16:18:50 -0500
Subject: Re: Error messages
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Content-Length: 3091
>Gordon Peterson <gep2@terabites.com> wrote (in extremely long lines):
Sorry if you don't like those... I've got the choice of not breaking lines, or
of breaking them manually, or of breaking them automatically at (say) 80
columns. Whichever I choose seems to have at least SOME nasty artifacts, and
someone bitches. I think I'm going to just set it back for force a break at 80
columns and let it go at that.
>> Although you COULD probably write [an assembler] in Prolog,
> I have to wonder if the benefits of making that choice are
> enough to justify the hassle.
> I just _have_ to ask: WHICH hassle?
I've written a **lot** of such stuff (admittedly in SNOBOL/SPITBOL rather than
Icon, but the principle is certainly similar). I don't think you have anything
like the same capabilities and ease of programming in Prolog that you have in
S*BOL or in Icon.
Now it could be that you don't program in S*BOL or Icon the way I do, or that
maybe you'd just rather do it (for whatever perverse reason) in Prolog. Hey,
whatever floats your own personal boat...
> Let's face it, analysing the input hasn't been the hard part of assembler
writing for decades.
Analyzing the input is a tiny part of the area where S*BOL or Icon shine. It's
the other areas surrounding the project where the real benefits show up. The
script compiler I wrote for the French Social Security Administration was
written in a day and a half, and produced the most beautifully complete and
detailed listings (cross references, formatted symbol tables, error summaries,
and even a listing table of contents) you ever saw. It would have taken at
least six months to write the same thing in C/C++, and maybe not a whole lot
less to have written it in Prolog.
> Writing the output is the tricky part. The real hassle is finding out what
the wretched output is supposed to look like.
I claim that THAT is only part of the hassle too. But hey, as I said, I've got
better things to do than to go through a detailed point-by-point argument with
you if you really want to do it in Prolog (or for that matter if you want to
write it to run on a Turing-machine emulator). It's your time and your money.
And you'll have to live the resulting product when you're done with it. Since
I'm reasonably sure that *I* will never have to use it, it matters really not
one whit to me. :-)
> For UNIX (maybe Windows too; I've never used Cygwin) anyone wanting to write
a new kind of assembler would be mad not to re-use as much of the GNU binutils
as practical. By all means put a smart new front end on an assembler, but
let someone else deal with the *real* hassle.
Well, I guess it depends on whether you want an assembler that works like
everyone else's or not. (Buf if you're happy with existing ones, why write a
new one at all?)
Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment! Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
fraudulent sham of representative government. Voters, remember it!